Serial No. 10/814,662 

Response to Office Action mailed December 12, 2008 
Remarks 

1. Introduction 

Claims 1 and 7-16, and 18-28 are pending. 

2. Objection 

Claim 18 was objected to because "second file" in line 7 was suggested to be "the second 
file." Applicants amend claim 18 to overcome the objection. 

3. Rejections under 35 U.S.C. §112, first paragraph 

Claims 1 and 7-16, and 18-28 were rejected xmder 35 U.S.C. §1 12, first paragraph as 
failing to comply with the written description requirement. Specifically, the Office Action stated 
that the specification fails to provide support for "the first file, the second file, and the third file 
being separate fi-om one another". Applicants provide some examples of support for the term 
below. 

One example disclosed in the specification of the first file may include the JAR file, one 
example of the second file may include the ADF file, and one example of the third file may 
include the SDF file. The specification teaches that the ADF file is separate fi:om the SDF file. 
For example, the specification teaches different conceptual drawings of the ADF file and the 
SDF file. An example of a conceptual drawing of an ADF file is depicted in Figure 2, 
reproduced below: 
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FIG. 2 
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See also paragraph [0016] ("Fig. 2 is a conceptual drawing illustrating a typical data structure of 
an ADF used in the system."). An example of a conceptual drawing of an SDF file is depicted in 
Figure 3, reproduced below: 

FIG. 3 
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See also paragraph [0017] ("Fig. 3 is a conceptual drawing illustrating a data structure of a SDF 
stored in a trusted server device of the system."). 
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Further, the specification teaches that the ADF file and the SDF file are stored in different 
devices. Figure 1 is an example of a block diagram of the architecture of the system: 

FIG. 1 




■--16 



The specification teaches that the ADF file may be stored in the CP server device 12. See 

paragraph [0031] ("Hard disk device 12A stores JAR files containing programs written in Java 

programming language, and ADFs containing data indicating information on their corresponding 

JAR files."); see also paragraph [0032]. The specification further teaches that the SDF file may 

be stored in the trusted server device 18. See paragraph [0037] ("Hard disk device 18A stores 

SDFs each of which corresponds to each of trusted Java-APPs."); see also paragraph [0017]. 

Finally, the specification teaches that each of the JAR file, ADF file, and the SDF file are 

separate firom one another. For example, the specification teaches that the JAR file, ADF file, 

and the SDF file may be sent separately to the mobile device. The following are examples of the 

separate transmission of the files: 

[0024] Java-AP software is downloaded to a mobile station in the delivery system as 
follows. First, the mobile station displays an introductory explanation of the Java-AP 
software for the user. When the user instructs the mobile station to download the Java- 
AP software, the mobile station first receives an ADF of the Java-AP software. Then the 
mobile station receives a file called a Security Description File (referred to as a 'SDF' 
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hereinafter) corresponding to the Java-AP software. Lastly, the mobile station receives a 
JAR file of the Java-AP software. SDF files contain data indicating behavior restrictions 
applicable to corresponding Java-APPs existing in a mobile station. Thus, when a mobile 
station runs a Java-APP, the mobile station controls, on the basis of conditions indicated 
in a corresponding SDF, behavior of an application provided by the Java-APP. 

Thus, the specification teaches that the mobile station first receives the ADF file. Then, the 

mobile device receives the SDF file. And finally, the mobile device receives the JAR file. 

Further, the specification provides examples in Figures 6 and 7 (reproduced below) of diagrams 

in which the sequence of separate download to the mobile station is performed. 

FIG. 6 
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FIG. 7 
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The specification teaches that CPU 16B in the mobile phone 16 requests the ADF file fi-om the 
CP server 12 in step S3 and receives the ADF file fi-om the CP server device 12 in step S4. See 
Figure 6. See also paragraph [0066]. Then, using the ADF file received in step S4, CPU 16B 
sends a request to the trusted server device 18 to receive the SDF file, as shown in step S5. See 
paragraph [0069] ("Accordingly, CPU 16B receives the SDF which corresponds to the Java- AFP 
from a storage location identified by the data indicating the trusted server domain 
'http://www.a.co,jp/melody.sdf . More concretely, CPU 16B establishes a TCP connection with 
trusted server device 18, generates a request message for transmitting the SDF, which is 
identified by the trusted server domain 'http://www.a.co.jp/melody.sdf indicated by the data 
contained in the ADF, and transmits the request message using the TCP cormection (step S5)."). 
The SDF file is then transmitted from the trusted server device 18 to the mobile phone 16 in step 
S6. See paragraph [0069] ("CPU 16B receives a response message containing the SDF in 
response to the request message (step S6), and discormects the TCP connection."). 
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The specification then teaches that the hash value calculated fi'om the ADF and the hash 
value from the SDF are compared. If the hash values are identical (see step SI 03 in Figure 7), 
the JAR file is downloaded. See step SI 04 in Figure 7. Specifically, the mobile phone 16 sends 
a request to the CP server device 12 to obtain the JAR file using the link contained in the ADF 
file previously received in step 84. See step S7 of Figure 6. The CP server device 12 then sends 
the JAR file to the mobile phone 16. See step S8 of Figure 6; see also paragraph [0074]. 

Thus, Applicants contend that the present application provides sufficient disclosure for 
the limitation "the first file, the second file, and the third file being separate firom one another". 
Therefore, Applicants request that the rejection be withdrawn. 

4. Conclusion 

The Examiner is invited to contact the undersigned attorneys for the Applicant via 
telephone if such communication would expedite this application. 

Respectfiilly submitted, 

d- ^ (. — 

Penn 

Registration No. 40,767 
Attomey for Applicant 

BRINKS HOFER GILSON & LIONE 
P.O. BOX 10395 
CfflCAGO, ILLINOIS 60610 
(312)321-4200 
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